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REMARKS 



This amendment is in response to the Office Action of May 6, 2005 in which 
claims 1-62 were rejected. 

Regarding the matter of the Examiner's statement in numbered paragraph 1 on 
page 2 about the interpretation of the term "get presence primitive" as being functionally 
equivalent to "subscription request" or any data structure being generated on a client 
system or device that is transmitted to a messaging server, referring to Fig. 17 of U.S. 
6,564,261, it is believed that the use of the term "get presence primitive" cannot be 
interpreted as broadly as the Examiner has suggested for the reasons stated below. 

As pointed out in M.P.E.P. 2111, the Examiner must give the claims their 
broadest reasonable interpretation consistent with the specification since applicant 
always has the opportunity to amend the claims during prosecution and broad 
interpretation by the Examiner reduces the possibility that the claim, once issued, will 
interpreted more broadly than is justified. 

The Courts have explained that reading a claim in light of the specification, to 
thereby interpret limitations explicitly recited in the claim, is a quite different thing from 
"reading limitations of the specification into a claim," to thereby narrow the scope of the 
claim by implicitly adding disclosed limitations which have no express basis in the 
claim. 

In the present claim, the word "get" in the claimed "get presence primitive" has 
the ordinary meaning of to obtain and bring "presence" where wanted or needed. The 
Examiner's interpretation is that the phrase "get presence" would include a subscription 
request. 
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However, the Examiner's point is incorrect because it is clear from the 
specification and the claims that the "get presence primitive" phrase is associated with 
and can only mean that it applies to one of the two models of acquisition of presence 
information presented in the present specification, i.e., the unsubscribed presence model 
claimed in claim 1 and described beginning at page 27, line 14 and ending at page 31, 
line 18. In the text at page 27 at lines 21-23, it is made clear that the "get presence 
message" is to request the presence information of another user with the information 
delivered back to the requesting user. The unsubscribed presence user is shown 
graphically in Fig. 3 A with a get presence message sent on the line 32 from a client 20 
to a server 27 such as also shown in Fig. 2A. 

The interpretation of the Examiner of the get presence primitive as embracing a 
subscription request is inconsistent with the specification's subsequent description of a 
"subscribed presence" model, as claimed in claim 4, for acquisition of presence 
information. The specification describes this beginning at page 31, line 20 as an 
altogether different mechanism where a requesting user sends a "subscribed presence 
message" such as the message shown on the line 80 of Fig. 4A to subscribe to someone 
else's presence information. The "subscribed presence" model of the present invention 
continues with this description through page 34, line 4. See also paragraphs [0151] 
through [0163] of the published application U.S. 2003/0037103 published February 20, 
2003. 

Thus, the "get presence primitive" phrase of claim 1 is only interpretable in light 
of the specification and claim 4 to mean that an unsubscribed user can issue a query to 
the presence server as indicated e.g. in the message flows presented in Fig. 3A to get 
presence information in a case where the user is not subscribed to presence. 

As suggested, the Examiner's interpretation is inconsistent with the claims 
themselves. Notice in particular that claim 4, which depends from claim 1 , contains the 
limitation that the data structure includes a "subscribed presence primitive" such as the 
primitive shown at reference numeral 80 in Fig. 4A and as described at page 31 lines 20- 
27 (see published application paragraphs [0151] - [0153]). 
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While it is true that the response of the server to the "subscribed presence 
primitive" is to provide the requesting user the requested presence information initially, 
in a manner similar to the "unsubscribed presence" model, the substance of the claimed 
limitation is different because the unsubscribed presence model, as claimed in claim 1, 
does not involve a subscription request whereafter the initial provision of presence 
information the subscribed user is updated with changes in the presence information of 
the other user. 

Therefore, the Examiner's interpretation is too broad and not justified by the 
specification or the other claims, particularly claim 4. In other words, it is to be noted 
that while the applicant has expressly claimed in a dependent claim (claim 4) from claim 
1 the "subscribe presence" aspect of the invention, there is no dependent claim from 
claim 1 that further limits the "get presence primitive" to an "unsubscribe presence" 
model. That is because the "get presence primitive" is clearly going to that limitation in 
the first place and should be interpreted in that way. If the applicant had inserted such a 
dependent claim, the applicant would be forced to agree with the Examiner's 
interpretation but it is clear that the "get presence primitive" when properly understood 
is to be read as an "unsubscribed presence" limitation, not a "subscription request" as 
suggested by the Examiner. 

Regarding the 35 U.S.C. § 102 rejection of claims 1-62 as being anticipated by 
Gudjonsson et al. (U.S. 6,564,261), Gudjonsson et al. has been studied carefully and 
applicant has the following remarks with respect to the details of the Examiner's 
rejection. 

The Examiner has pointed to Fig. 17 of Gudjonsson et al. in numbered paragraph 
on page 2 of the Detailed Action. That figure shows a data structure for the contact 
status service disclosed by Gudjonsson et al. on an exemplary connection server. Notice 
that Fig. 17 uses a subscription model, unlike claim 1 of the present application, which 
introduces the concept an unsubscribe presence request in the form of a "get presence 
primitive" such as shown in detail in Table 3 on page 37 of the present specification. 
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Notice that the "get presence primitive" may include various information elements 
including several that are explicitly claimed in claim 1, i.e., a requesting user identifier, 
a requested user identifier, and a list of presence values requested. None of this is shown 
in Fig. 17 or any of the other data structures shown in Figs. 16, 18(a) or 18(b) of 
Gudjonsson et al. Notice in column 26, line 44, that the online status is "subscribed" 
from the responsible user server by the connection server that is watching the user as 
done in a typical subscription service. Besides not showing an unsubscribe presence 
model, the Gudjonsson et al. reference fails to show the various information elements 
claimed in claim 1 for the "get presence" primitive. The closest thing that could be 
found in the Gudjonsson et al. specification appears at column 8, lines 53-54 where each 
user may be provided with the ability to define arbitrary sets of data related to an 
identity, i.e., presence data of the user. It is noted that the "list" recited at column 11, 
line 57 of the paragraph cited by the Examiner refers back to "contact" lists appearing at 
line 46 of the same paragraph and is not a list of presence values of a user. Such a list of 
presence values can be supplied as an information element of a presence primitive for 
example as shown in the last information element of Table 4 of the present specification 
(see page 38). 

Notice that the paragraph cited by the Examiner at column 1 1, lines 44-64, refers 
to Fig. 8 as an example wherein it is clear that the context is a presence subscription 
scenario where the "buddies" have already been identified by the user and their presence 
information is updated and shown at a moment's notice such as by opening "the ball" 
and exposing a variety of functions including the contact list shown in Fig. 8 illustrating 
a portion of such a list that is maintained by the user that includes other individuals that 
the user knows and has contact with and for which the online status of these users is 
shown in order to reflect when a given buddy is currently logged in to the system or not, 
thus giving information whether that buddy is immediately reachable. 

Although the Gudjonsson et al. reference mentions that the users can have a 
range of possible statuses that they can specify, such as "do not disturb" or "temporarily 
unavailable," the "list" that is referred to at line 57 is not a list of such statuses because 
the only place the word "list" is used (previously in the same paragraph) is at line 46 
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which refers to a "contact list" not a list of possible statuses. Notice the use of the 
indefinite article "a" modifying "contact list" and the definite article "the" modifying 
the word "list" at line 57. The word contact list is used again at column 12, line 55 and it 
is clear that "the list" is a contact list. 

Although the Gudjonsson et al. reference hints at "a range of possible statuses" 
at column 11, line 55 and in the passage cited above at column 8, lines 53-54, this is far 
removed from the teaching from the present specification where in addition to the two 
models for acquisition of presence information ("unsubscribed" presence and 
"subscribed" presence), the present invention teaches actually how to allow for future 
expansion of presence values for presence services by providing for the definition of a 
minimum set of registered presence attributes and values. See the present specification 
at page 39, line 6 through page 43, line 6 (as published in paragraph [0176] - [0206] on 
pages 13 and 14 of U.S. 2003/0037103). 

In summary, the Gudjonsson et al. reference does not show or suggest an 
"unsubscribe presence" model as claimed in claim 1 nor does the Gudjonsson et al. 
reference show the claimed list of presence values either requested or supplied. 

Withdrawal of the 35 U.S.C. § 102(e) rejection of claim 1 is requested. 

Regarding claim 2, the Examiner has referred to Fig. 3 A and the description 
thereof appearing in the specification at page 27, line 21 wherein the get presence 
message 32 requests the presence information of another user as shown on a line 32 in 
Fig. 3 A. As indicated at page 27, lines 22-23, presence information 33 is delivered back 
to the requesting user. However, as also shown in Fig. 3 A and as claimed in claim 2, an 
option with an authorization sequence may occur between the "get presence" message 
on the line 32 and the presence delivery on the line 33. Specifically, beginning in the 
specification at page 28, line 12, a authorization sequence is described wherein after the 
unsubscribed request for presence information on the line 32 an authorization request 36 
may be sent to the user to authorize the presence information, as shown by an 
authorization message at line 37. This is the subject matter of claim 2 and is to be 
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understood in the context of the "unsubscribe presence" model claimed in claim 1 as 
explained previously. Therefore, claim 2 also is limited to the "unsubscribe presence" 
model claimed in claim 1 which is different from the subscription request identified by 
the Examiner in the Gudjonsson et al. reference. 

Withdrawal of the 35 U.S.C. § 102(e) rejection of claim 2 is requested. 

Regarding claim 18, it is a device claim dependent from claim 1 and is also 
limited to the "unsubscribe presence" model claimed in claim 1, as distinguished from 
the presence subscription of the Gudjonsson et al. reference. Similarly, claims 19-21 
claim a system with a data structure according to the "unsubscribe presence" model 
claimed in claim 1 as distinguished from the "subscription request" identified by the 
Examiner in the Gudjonsson et al. reference, et al. 

Withdrawal of the 35 U.S.C. § 102(e) rejection of claims 18-21 is requested. 

Regarding independent claim 22, and independent claim 42 which closely 
resembles claim 22 except being a server instead of a management method for use by a 
server, the Examiner again points to Gudjonsson et al. for disclosing presence 
information service management for use by a server. 

Both claims 22 and 42 are somewhat narrower than claim 1 in that they claim 
both the unsubscribed presence and subscribed presence models within the same 
independent claim. This can be seen in the third step of claim 22 as well as the third 
element of claim 42 wherein it is made clear that the server receives presence 
information request messages from users that include users requesting presence 
information to which a response is required and subscribers initially subscribing to 
presence information to which on-going responses including requested presence 
information are required. 
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The Gudjonsson et al. reference does not disclose an unsubscribed presence 
model combined with a subscribed presence model, as is presently claimed in claims 22 
and 42. 

The passage cited at column three, lines 1-13 of Gudjonsson et al. shows (1) 
dynamic user properties, (2) contact list and contact notification and (3) routing service 
but does not shown either an unsubscribed presence model or a combination of a 
unsubscribed presence model with a subscribed presence model. 

The passages cited at column 17, lines 19-37 refer to subscribed contact status 
services only, not unsubscribed. The definitions in column 6, lines 44-55 do not disclose 
a user request of presence information to which a response is required as distinguished 
from subscribing users initially subscribing to presence information to which on-going 
responses including requested presence information is required. Although the word 
"request" is defined in general it does not give any further details of the nature of the 
request. The passages following in column 1 1, beginning at line 31 and ending at line 64 
again relate to subscribed presence, not unsubscribed presence combined with 
subscribed presence, as in claims 22 and 42. The passages cited at column 26, lines 40- 
64 have already been discussed in connection with claim 1 . 

For the same reasons as advanced in connection with the rejection of claim 1, 
Fig. 1 7 of the reference does not show the kind of data structure that is needed for 
carrying out the unsubscribed presence model claimed in claims 22 and 42 wherein both 
(a) users requesting presence information to which a response is required and (b) 
subscribing users initially subscribing to presence information to which on-going 
responses including requested presence information are required. 

Therefore, the 35 U.S.C. § 102(e) rejection of claims 22 and 42 is inapplicable 
and withdrawal thereof is requested. 

With regard to claim 62, this claim is a holdover from the provisional application 
and the original intention was to cancel it. However, since the fee has been paid, it is 
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amended to be consistent with the rest of the claims as subsequently developed for the 
regular U.S. application. Claim 62 now depends from claim 1 and claims a system for 
the management of presence information comprising a client and a server able to 
exchange presence information having a data structure according to claim 1 . The 
patentability of claim 1 over the applied reference to Gudjonsson et al. has been 
explained already above in connection with claim 1 and since claim 62 now depends 
from claim 1 it is patentable for the same reasons and withdrawal of the rejection thereof 
is requested. 

The objections and rejections of the Office Action of May 6, 2005, having been 
obviated by amendment or shown to be inapplicable, withdrawal thereof is requested 
and passage of claims 1-62 to issue is solicited. 
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